Dave Matthews <dma### [at] wrmnwestmnscuedu> wrote:
> >   (By the way, even if you "translate" a torus or apply other
> > transformations to it, the torus will still be sitting in the
> > origin, so the transformations you apply to the torus will
> > actually not affect the complexity of the ray-torus intersection
> > solving.)

> Uh-oh.  I was following you, agreeing with you, nodding my head, (and you
> are right about the simplifications, at least in hand calculations, I've
> done them; I don't know anything about the programming) until I got to this
> part.  Could you explain this a bit further, at the risk of hijacking the
> thread?

  As I explained recently in another thread (and probably another group),
transformations are not applied to objects. Instead, the inverse
transformations are applied to the ray before testing its intersections
against the object. (More explicitly: All transformations are collected
into a single transformation matrix, the inverse of this matrix is
calculated (at parse time), and when testing the ray against the object,
the ray is first transformed with this inverse matrix.)

  This has clear advantages: *Any* raytraceable object can be "transformed"
with the standard transformations. In fact, if you added a new object to
POV-Ray, you wouldn't have to worry about its transformations: The
transformation logic in POV-Ray already takes care of this for you,
regardless of your object. (And in fact, many primitives may be so
complicated that transformations would not be possible to be applied
to them at all.)

  The disadvantage is that since the ray must keep straight even after
transforming it, only linear transformations are possible. (This is
the reason why there are no non-linear transformations in POV-Ray.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message